Hi, tests/cli-export-date-range.test.ts uses UTC ("Z") timestamps but --from/--to are parsed as local dates, so the “out-of-range” session can fall within the local 2026-04-10 window in some timezones and be included, breaking the test deterministically depending on TZ.

Severity: remediation recommended | Category: reliability

How to fix: Force TZ=UTC in test

Agent prompt to fix - you can give this to your LLM of choice:

Issue description

The integration test for codeburn export --from/--to is timezone-dependent because it writes UTC timestamps (...Z) but the CLI’s --from/--to are parsed as local dates.

Issue Context

• parseDateRangeFlags() builds local-time Date boundaries.
• parseSessionFile() compares new Date(firstCallTs) against those boundaries.
• The test data uses 2026-04-11T09:01:00Z, which can still be local 2026-04-10 in negative timezones.

Fix Focus Areas

• Set TZ=UTC in the spawned CLI environment to make the test deterministic.
  • tests/cli-export-date-range.test.ts[8-17]

(Alternative: run the spawned CLI with an explicit timezone via env and/or adjust the timestamp generation, but note there is no single pair of Z timestamps that will map to fixed local calendar days across all timezones without forcing TZ.)

Found by Qodo code review

Thanks for catching this. Good point: the CLI parses --from / --to as local date boundaries, while the fixture timestamps were UTC strings, so the test could vary by machine timezone.

Fixed in b1d80e2 by setting TZ=UTC in the spawned CLI environment for tests/cli-export-date-range.test.ts.

Validated with:

• npx tsc --noEmit
• npx vitest run tests/cli-export-date-range.test.ts tests/date-range-filter.test.ts tests/export.test.ts

GitHub checks are green now as well.